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Claims 1-24 arc pending in the present application. Claims 5, 12, and 19 arc 
amended to recite "Simple Network Management h'olocol" rather than "System Network 
Message Protocol* 1 ; claim 1 1 is amended for grammatical purposes; and claims 22-24 arc 
added to recite the feature of selecting, in response to a condition or an event, a list of 
users based on profile information in the profile tabic wherein the list of users is a subset 
of the plurality of users. Reconsideration of the chums is respectfully requested. 

1, 35 U.S.(\ § 103, Alleged Obviousness of claims 1, 8, and 15 

The Office Action rejects claims 1, 8, and 1 5 under 35 U.S.C § 103(a) as being 
allegedly unpatentable over Stupek, Jr> ct al, (U.S. Patent No. 6,131,1 18). This rejection 
is respectfully traversed. 

With regard to claims 1, 8 and 15, the Office Action slates: 

As to claims 1 , 8, and 1 5, Stupek a flexible display of management 
dala in programmable event driven processing system, the system 
comprises a server for detecting and receiving an event from network 
devices and transmits the event notification to the user based on the event 
defined in database, the system comprising 

profiling in a profile table each one of said plurality of users 
(Slupek teaches, a network management server, which included a database 
lliat containing user preferences, enabled the user to specify specific event 
monitoring, Col. 5, lines 46-67, database and user preference is considered 
equivalent to profile table); 

transmitting said alarm message to I he list of users wherein said 
users have been selected from said profile iablc, said alarm message being 
displayed on a screen of a workstation associated with each selected user 
if said workstation is on (Stupek leaches, the management server enabled 
the user to select and view various infonnulion including the selected 
events, Col 6, lines 7-15. Inherently, Stupek also teaches transmitting the 
alarm or event messages from the management server to user terminal). 

Slupek does not explicitly disclose an administrator is associated 
with the server. 

Official Notice is taken (sec MPEP 2144.03) that administrator 
processed alarm was well known in the ncswork management system. 

Thus, it would have been obvious to one of ordinary skill in the art 
at ihe lime of the invention was made to associated network administrator 
with Stupek network management server In process alann of event 
notification event. Doing so, the management capabilities, flexibility 
would be enhanced, because the system can be intervened by a human, 
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which would allow the system to be configured to accommodate wilh 
most if not all situations. 
Office Action dated September 17, 2003, pages 2-3. 

Claim 1, which is representative of claims & and 15 wilh regard to similarly 

recited subject matter, reads as follows: 

1 , System for broadcasting alarm mcs.-nges from a server to a list o f 
users among a plurality of multi-platform users sharing the server in a data 
transmission network operating under Internet Protocol (IP) and vising 
Java language, said system being characterized in that it comprises: 

a profile table containing profiles of each one of said plurality of 
users; and 

processing and transmitting means enabling an administrator 
associated with said server to transmit alarm messages to the list of users 
wherein said users have been selected from said profile table , said alarm 
messages being displayed on a screen of a workstation associated with 
each selected user if said workstation is running, (emphasis added) 

Stupek, Jr. (Stupclc from hereon) is directed to a network management system that 
facilitates and performs programmable event driven processing including event detection 
logic that receives and processes any of a plurality of event notifications transmitted via 
the network. The network management server and the managed devices can be accessed 
remotely from a client system via an intranet or ihtf Internet using a web browser. The 
client, if authorized, can access and view the management information regarding the 
managed devices. The client sends an HTTP request to a network management server or 
a managed device for a web page which is then passed back to the client system. Once 
die client logs onto the webpagc, management information can be monitored from the 
client device and the client can perform administrative duties. (Stupek, Column 1, lines 
55-60 and 63-67 and Column 6, lines 15-30) 

Thus, Stupek is concerned with performing network management functions, much 
like the Simple Network Management protocol (SMMP) and the Desktop Management 
Interface (DMI), across the Internet using a web browser. Although Stupek may allow 
for the client to define: certain preferences and identify certain data to be monitored, there 
is nothing in Stupek that teaches or even suggests ;m administrator associated with a 
seivcr sending alarm messages to a list of users, selected from a plurality of users within 
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a profile table as recited in claims 1 , 8, and 1 5 of the present invention. The Office 

Action alleges litis feature is taught in the following section of Stupek: 

The management server 102 enables the user to select a managed 
element 104 and view detailed information about that device. The 
management server 102 also enables a user to create device groups for 
business process views by filtering for selected devices and for selected 
events of those devices. The management server 102 handles events, such 
as SNMP traps and HTTP alerts, logs the events, and allows a user to set 
event filters. (Column 6, lines 7-14) 

This section merely describes the interaction between the user (administrator) and 
the management server. The user may view device information or set tiser specified 
monitoring preferences, enabled by the management server. Nowhere in this section or 
any other section of Stupek is it taught or suggested to transmit alarm messages to a list 
of users, selected from a plurality of users within a profile table as recited in claims 1, 8, 
and 15 of the present invention. 

Furthermore, the Office Action states, "Inherently, Stupek also teaches 
transmitting un alarm or event message from the management server to user terminal" 
(Office Action, page 3) While a transfer of data in Stupek may occur from the 
management server to the user terminal, the data Uansfer is not in response to a list of 
users being selected from a plurality of users within a profile table as recited in claims 1, 
8, and IS of the present invention. Rather the information is transferred from the 
management server to the user terminal in response to a request for information made by 
Ihe user. 

In addition, Applicant agrees with the Office Action that Stupek docs not teach or 
simijcst that an administrator is associated with Ihs server. However, the Office Action 
alleges this feature is old and well known. While an administrator being associated with 
a server may be old and well known, the present invention does not simply claim that an 
administrator is associated with the sewer. Rather the present invention recites having an 
administrator associated with the server transmit 9 (arm messages to the list of users 
wherein the users have been selected from a profile table. Furthermore, this is not the 
problem that Stupek is concerned with and thus, Stupek does not even hint at an 
administrator associated with the server transmits alarm messages to the list of users 
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wherein the users have been selected from a profile table. Applicant respectful ly requests 
that Ihe Examiner cite a reference in support of the allegation that this feature is old and 
well known. While the general concept of an administrator-processed alarm may be old 
and well known, Applicant respectfully submits that an administrator transmitting alarm 
messages to the lisl of users selected based on user profiles as recited in claims 1 , 8, and 
15 of the present invention is not. Therefore, Applicant respectfully submits lhat Stupck 
docs nol teach or suggest the features of independent claims 1, 8, and 15. 

Moreover, Stupck docs not teach, suggest, or give any incentive to make the 
needed changes to result in the features of claims !, 8, and 15 of the presently claimed 
invention. Absent the Examiner pointing out somi; teaching or incentive to implement 
Stupck to include alarm messages sent by an administrator to a list of users, selected from 
a plurality of users within a profile table, one of ordinary skill in the art would not be led 
to modify Stupck to reach the present invention when the reference is examined as a 
whole. Absent some teaching, suggestion, or incentive to modify Stupck in this manner, 
the presently claimed invention can be reached only through an improper use of hindsight 
using the Applicant's disclosure as a template to make the necessary changes to reach the 
claimed invention. 

In view of the above, Applicant submits that Stupck docs not teach or suggest 
each and every feature of independent claims 1 , 8, and 1 5 as required under 35 U.S.C. § 
1 03(a). At least by virtue of their dependency on claims 1, 8, and 15, Stupek does not 
teach or suggest each and every feature of dependent claims 2-7, 9-14, and 16-21. 
Accordingly, Applicant respectfully requests withdrawal of the rejection of claims 1 -21 
under 35 U.S.C. § 103(a). 

II. 35 LLS-C. 3 103. Alleged Obviousness of claims 2-5, 7. 9-12. 14, 16-19, and 21 

The Oil ice Action rejects claims 2-5, 7, 9-12, 14, 16-19, and 21 under 35 U.S.C. § 
1 03(a) as being allegedly unpatentable over Stupek, Jr. ct al. (U.S. Patent No, 6,1 3 1 ,11 8) 
and in further view of Event Nolificr, a Pattern f or Event Notification by Drala software 
published in J ava Report, July 1 998, Volume 3, Number 7 (Drala from hereon). 

Tins rejection is respectfully traversed for ;it least the same reasons as noted 
above with respect to claims 1, 8, and 15 from which claims 2-5, 7, 9-12, 14, 16-19, and 
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21 depend. Specifically, Stupek docs not teach or suggest an administrator associated 
with a server sending alarm messages to a list of users, selected from a plurality of users 
within a profile table. In addition, Drala docs not provide for the deficiencies of Stupck. 

Drala is directed towards a method for event notification in a network 
management system. Drala is concerned with the difficulty in adding managed objects to 
a network. In a simplistic approach, a managed object must scud notification of problems 
to both a console and a paging system. In order to change the interface to the console or 
the paging system, or add an electronic mail system, every managed object must be 
modified. Thus, Drala teaches a method for minimizing the number of dependencies and 
interconnections between objects to prevent the sy/lcm from becoming difficult to 
modify. Therefore, Drala is not concerned with directing messages to a set of users on a 
network, Drala merely teaches an event management scheme that simplifies modifying 
components within the network management system by making more independent the 
managed objects from each other and from the console and paging system. Thus, Drala 
also does not teach or suggest an administrator associated with a server sending alarm 
messages to a list of users, selected from a plurality of users within a profile table as 
recited in claims 1, 8, and 1 5 of the present invention. (Drala, Motivation section, pages 
2-3) 

In addition to the above, neither Stupek no* Drala, either alone or in combination 
teach or suggest all of the specific features recited in dependent claims 2-5, 7, 9-12, 14, 
1 6-19, and 21 . For example, with regard to claims 4, 1 1, and 1 8, neither Stupck nor 
Drala, alone or in combination teaches or suggests an alarm message is automatically sent 
at the occurrence of a condition or event. As noted above with regard to claims 1, 8, and 
1 5, Stupck tenches a method for accessing information via the Internet by logging into 
the network management system and requesting information from the management 
system. Nowhere docs Stupck even allude to a message being sent from a server 
automatically, in other words, without a request from the administrator. The user of the 
Stupck system is required to request the information that is to be viewed at the client. 
Further, with regard to the discussion above, Drala is not concerned at all with the 
transmission of alarm messages to a list ofuscrs. Uathcr, Drala is focused on a more 
amenable system for modifying and changing components. 
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Furthermore, Applicant agrees with the Ofljce Action thai neither Stupek nor 
Drab teaches or suggests the alarm messages arc previously written by the administrator 
as also recited in claims 4, 1 1, and 18. Rather than actually finding this feature in any . 
secondary reference, however, the Examiner merely alleges that this feature is old and 
well known. Applicant respectfully disagrees and requests that the Examiner cite a 
reference in support of the allegation that alarm messages, previously written by an 
administrator arc automatically scut to a set of users based on profile information at the 
occurrence of a condition or an event. Furthermore, neither Stupek nor Drala is concerned 
with sending alarm messages to a list of users, selected from a plurality of users within a 
profile table, regardless of whether the messages were previously written. Thus, neither 
Stupek nor Drala even suggcsls alarm messages, previously written by the administrator arc 
automatically sent at the occurrence of a condition or an event as recited in claims 4, 1 1, 
and 18 of the present invention. 

Additionally, with regard to claim 5, 12, and 19, neither Stupek nor Drala, alone 
or in combination teaches or suggests that alarm messages arc automatically sent when 
any specific resource monitored by an SNMP becomes unavailable. As with the 
discussion above, Stupek teaches a method for accessing information via the Internet by 
logging into the network management system and requesting information from the 
management system, Stupek does not teach or suggest anywhere that a message is sent 
from a server automatically. The user of the Stupdt system is required to request the 
information thai is to bo viewed at the client. Further, with regard to the discussion 
above, Drala is not concerned at all with the transmission of alarm messages to a list of 
users. Rather, Drala is focused on a system that is more amenable to modification. 

Furthermore, with regard to claims 3, 10, and 17, Applicant agrees with the Office 
Aclion that neither Stupek nor Drala teaches or suggests the alarm messages are written 
and manually sent by the administrator when necessary, The Office Aclion states that a 
user can compose a short message and manually send that message as in a conventional 
e-mail system. While this may be true, the present invention does not claim an e-mail 
system or the like. The present invention actually claims that alarm messages are written 
and manually sent by an administrator when necessary. In other words, an administrator 
sends an alarm message in response to a condition or an event that necessitates an alarm 
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mossagc. Neither Stupek nor Drala even suggest such a feature. This is, in part, because 
neither Stupck nor Drala leach or suggest communication of any kind between the 
administrator and a list of users, Thus, unless the Examiner can cite a reference that 
teaches that alarm messages are written and manually sent by the administrator when 
necessary, Applicant is entitled to a grant of patent on claims 3, 10, and 17. 

111. 35 U.S.C. S 103, Alleged Obviousness of claims 6, 13, and 20 

The Office Action rejects claims 6, 13, and 20 under 35 U.S.C. § 103(a) as being 
allegedly unpatentable over Stupck, Jr. ct al. (U.S. Patent No. 6,13 1,1 18) and in further 
view of Event Nolifler. a Pattern for Event Notification by Drala software published in 
Java Report, July 199S, Volume 3, Number 7 and still in further view of Cote et al. (U.S. 
Patent No, 6,021,262), This rejection is respectfully traversed for at least the same 
reasons as noted above with regard to claims 1 , 8, smd 1 5 from which claims 6, 1 3, and 
20 depend. 

As noted above with regard to claims 1 , 8, and 1 5, neither Stupek nor Drala, 
cither alone or in combination, teach or suggest an administrator associated with a server 
sending alarm messages to a list of users, selected from a plurality of users within a 
profile table. In addition, Cote does not provide for the deficiencies of the proposed 
Stupck-Drala combination. Cote is directed to a system for automatically monitoring the 
status of messaging software. If a deficiency, such as a software condition or a link 
condition, is detected in the messaging software, the administrator is notified regardless 
of whether the message system is non functional. At the point of notification, the 
deficiency can be resolved by, for example, restarting the server which controls the 
messaging service. (Cote, Column 1, line 66 - Column 2, line 57) 

Thus, Cote is concerned with deficiencies in a messaging system. Cote docs not 
address any issues to which either Stupek or Drala are directed. Thus, one of ordinary 
skill in the art, presented with only Stupck, Drala, rind Cote, and without prior knowledge 
of the Applicant's claimed invention, would not have found it obvious to combine a 
network management system that facilitates and performs programmable event driven 
processing over the Internet as in Stupek, with a system directed toward minimizing 
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network modification complexity as in Drala, and further combining this concoclion wilh 
Cote, which discloses a system for monitoring deficiencies of messaging software. 

Furthermore, even if one of ordinary skill in the art were somehow motivated to 
combine these references, one would still not be motivated to modify the resulting 
combination in the specific manner to arrive at the features recited in claims 1 , 8, and 1 5. 
Thus, the alleged combination can only be the result of impermissible hindsight 
reconstruction using Applicant's own disclosure as a guide, While Applicant understands 
that all examination entails some measure of hindsight, when the rejection is based 
completely on hindsight, as in the present case, to the exclusion of what can be gleaned 
from the references, then the rejection is improper and should be withdrawn. 

IV. Nov Claims 22^24 

New claims 22-24 arc added to the application. These claims are patentable at 
least by virtue of their dependency on claims 1 , 8, and 15, Further, these claims include 
additional features not shown or suggested by the cited references. More particularly, 
claims 22-24 recite the feature of selecting, in response to a condition or an event, a list 
of users based on profile information in the profile table wherein the list of users is a 
subset of the plurality of users. Support for the newly added features of claims 22-24 is 
found on at least pages 3-4 of the present specification. Thus, it is respectfully requested 
that these claims be allowed. 
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V, Conclusion 

It is respectfully urged that the subject application is patentable over Stupck, 
Drala, and Cote and is now in condilion for allowahce. The Examiner is invited to call 
(he undersigned at the below-listed telephone number if in the opinion of the Examiner 
such a telephone conference would expedite or aid ihe prosecution and examination of 
this application, 
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